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© A distributed file system uses objects to model 
the behavior of components of the distributed file 
system. Each object has an associated logical path 
name and physical address. An aggregation of all 
the logical path names comprises a distributed name 
space which can be logically partitioned into do- 
mains. Each domain includes a domain folder object 



which^maps logical path names of objects in the 
domain containing the domain folder object, into 
addresses in the distributed system where the ob- 
jects are stored. The addresses of the objects are 
used to access the objects in order to retrieve in- 
formation from the distributed system. 
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Technical Field 

This invention relates generally to file systems 
and, more specifically, to a distributed file system 
for a distributed system. 

Background of the Invention 

Existing distributed systems provide distributed 
file systems which are capable of retrieving files 
from different locations throughout the distributed 
system. Existing distributed systems gain access 
to files by mapping a logical path name which 
uniquely identifies the file into a physical address 
at which the file is stored. The logical path name of 
the file is intrinsically tied to the physical address* 
of the files. 

As the size of the distributed system increases 
it becomes more difficult, due to the sheer number 
of logical path names active in the distributed sys- 
tem, to manage the logical path names in a way 
which provides for efficient mappings of logical 
path names into physical addresses. In addition, it 
becomes more difficult to provide a single, consis- 
tent name space to a user of the distributed sys- 
tem from any location on the distributed system. 
Prior systems have instead provided a fragmented 
name space to users of the distributed system. 

Summary of the Invention 

The difficulties of the prior art are overcome by 
the present invention. In accordance with one as- 
pect of the present invention, a distributed system 
has a distributed name space of objects wherein 
each object has both a logical name that uniquely 
identifies the object and a corresponding address. 
The objects are grouped into logical domains which 
are organized into a hierarchical structure. Each 
domain may have a superior domain in the hierar- 
chical structure and may have one or more subor- 
dinate domains in the hierarchical structure. A do- 
main controller component is provided for each 
domain. Each domain controller component holds a 
cache such as a prefix table. The cache holds an 
entry for a logical name in the distributed name 
space for a domain controller component for any 
immediately superior domain. In addition, the 
cache also holds an entry for the logical name, in 
the distributed name space for a domain controller 
in any immediately subordinate domains. Each en- 
try for the above discussed domain controller com- 
ponents includes an address for the domain con- 
troller component. 

A first computer component is provided in the 
distributed system for processing requests for in- 
formation from the distributed system. The first 
computer component includes a second cache 



which stores entries for portions of the logical 
names in the distributed name space. Each entry 
includes an address of an object in the distributed 
system that is identified by the associated portion, 

5 The request is to access an object at the first 
computer component is received. The request in- 
cludes a logical name corresponding to the object 
in the distributed system. It is determined whether 
a portion of the logical name is stored in the cache 

w of the first computer component. Where it is deter- 
mined that there is not an entry for a portion of the 
logical name in the cache of the first computer 
component, several steps are performed. 

First, the address of the domain controller 

75 component for the domain containing the first com- 
puter component is retrieved from the cache of the 
first computer component. The logical name is sent 
to the domain controller component that contains 
the first computer component. An address cor- 

20 responding to the logical name of the object is 
retrieved from the cache of the domain controller 
component for the domain containing the first com- 
puter component. The object is then accessed at 
the retrieved address. 

25 In accordance with another aspect of the 

present invention a distributed system has a first 
storage media partition and a second storage me- 
dia partition. A first file system is run on the first 
storage media partition to store and manage files. 

30 Similarly, a second file system is run on the sec- 
ond storage media partition to store and manage 
files. The first and second storage media partitions 
may be part of a same computer system, may 
merely constitute separate storage devices or may 

35 even be separate computers. The second file sys- 
tem differs from the first file system. A distributed 
file system is provided. The distributed file system 
furnishes a distributed name space that includes 
files in the first storage media partition and files in 

40 the second storage media partition. The distributed 
file system furnishes name resolution services to 
-the first file system and the second file system. 
The distributed file system is transparent to the 
first file system and the second file system. 

45 In accordance with a further aspect of the 

present invention, a distributed system runs a first 
network operating system on a computer system 
and a second network operating system on a com- 
puter system. The second network operating sys- 

50 tern differs from the first network operating system. 
A distributed file system is provided over the net- 
work operating systems and furnishes the distrib- 
uted system with a unified distributed name space 
of files. The distributed file system furnishes name 

55 resolution services to the network operating sys- 
tems. The distributed name space includes files 
stored on the computer system that runs the first 
network operating system and files stored on the 
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computer system that runs the second network 
operating system. The distributed file system is 
transparent to the network operating systems. 

In accordance with a still further aspect of the 
present invention, a distributed system has multiple 
components. The components of the distributed 
system are logically partitioned into domains. Each 
domain is self-contained such that it may operate 
independently of other domains. The distributed 
system runs a network operating system in a first 
domain that implements a security policy. The do- 
main implements a security policy that differs from 
the first security policy and is independent of the 
distributed file system. 

In accordance with an additional aspect of the 
present invention, a method is practiced in the 
distributed system. In this method, a distributed file 
system provides^ distributed name space. At least 
one underlying file system is provided in the dis- 
tributed system for performing file system oper- 
ations. Objects upon which file system operations 
may be performed are visible in the distributed 
name space and at least one object upon which file 
system operations may not be performed is also 
visible in the distributed name space. 

Brief Description of the Drawings 

Figure 1 . is a block diagram of a distributed 
system for practicing a preferred embodiment of 
the present invention. 

Figure 2 is a more detailed block diagram of a 
domain controller of Figure 1. 

Figure 3 illustrates a simplified example of dis- 
tributed name space for the preferred embodiment 
of the present invention. 

. Figure 4 is a flow chart illustrating the steps 
performed by an access object routine in the pre- 
ferred embodiment of the present invention. 

Figure 5 is a more detailed block diagram of a 
workstation in accordance with the preferred em- 
bodiment of the present invention. 

Figure 6 is a flow chart of a retrieve storage 
location routine used in the preferred embodiment 
of the present invention. 

Figure 7 is a flow chart of the perform server 
name resolution routine of the preferred embodi- 
ment of the present invention. 

Figure 8 is a diagram illustrating the format of 
the prefix table in the preferred embodiment of the 
present invention. 

. Figure 9 is a flow chart of the steps performed 
by the get referral routine in the preferred embodi- 
ment of the present invention. 

Figure 10 is a flow chart of steps performed by 
the initialize domain root volume local information 
routine of the preferred embodiment of the present 
invention. 



Figure 11 is a block diagram of a domain 
controller in accordance with the preferred embodi- 
ment of the present invention. 

Figure 12 is a flow chart of the initialize domain 
s non-root volume local information routine of the 
preferred embodiment of the present invention. 

Figure 13 is a flow chart illustrating the steps 
performed by the initialize interdomain information 
routine of the preferred embodiment of the present 
w invention. 

Figure 14 is a flow chart of the steps per- 
formed by the initialize workstation prefix table of 
the preferred embodiment of the present invention. 
Figure 15 is a flow chart of the steps per- 
75 formed by the initialize domain controller prefix 
table routine of the preferred embodiment of the 
present invention. 

Detailed Description of the Invention 

20 

A preferred embodiment of the present inven- 
tion provides a distributed file system. The distrib- 
uted file system of the preferred embodiment of 
the present invention is implemented by compo- 

25 nents distributed across a distributed system. The 
distributed file system provides logical transpar- 
ency for named objects in the file system so that 
the path names of objects in the system are not 
intrinsically tied to their physical location. In addi- 

30 tion, the distributed file system organizes a name 
space for the distributed system into a single logi- 
cal tree structure. The distributed file system parti- 
tions the distributed system into administrative do- 
mains (which will be described in more detail be- 

35 low) which may each implement separate admin- 
istrative and security policies. The security policy 
practiced by a domain may be independent of the 
distributed file system. The distributed file system 
provides a super structure for "tying" together por- 

4o tions of the distributed system having heteroge- 
neous file systems and heterogeneous network op- 
erating systems. The distributed file system pro- 
vides name resolution services to the file systems 
and the network operating system, but the distrib- 

45 uted file system is transparent to the file systems 
and the network operating system. 

Figure 1 is a block diagram of a distributed 
system 100 that is suitable for practicing the pre- 
ferred embodiment of the present invention. Those 

so skilled in the art will appreciate that the distributed 
system configuration shown in Figure 1 is merely 
illustrative. Other distributed system configurations 
may also be used to practice the present invention. 
The distributed system 100 includes worksta- 

55 tions 101, input/output (I/O) devices 102, network 
servers 103, secondary storage devices 104, and 
domain controllers 106. The workstations 101 and 
networks servers 103 may include internal mem- 
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ory, a processor, and other components. The net- 
work servers 103 run network operating systems. 
The secondary storage devices 104 may include 
disk drive devices or other suitable secondary stor- 
age components. It should be appreciated that 
software and data are stored within the internal 
memory of the workstations 101 and the domain 
controllers 106. In addition, software and data are, 
likewise, stored in the secondary storage devices 
104. 

The components included in the distributed 
system 100 are logically partitioned into domains 
108A, 108B and 108C, wherein each domain in- 
cludes a subset of the hardware and software com- 
ponents of the distributed system 100. Each do- 
main may include one or more networks running" 
network operating systems. A domain 108A, 108B 
or 108C may correspond with an administrative 
portion of an organization. A domain 108A, 108B 
and 108C is a self-contained and self-sufficient unit 
for purposes of administration and security. Do- 
mains facilitate scaling of the distributed system 
100 so that components may be readily added or 
removed from the system. 

In order to more fully understand the notion of 
a "domain," it is helpful to consider an example. 
Suppose that a distributed system is used in a 
corporation having multiple departments. In such 
an environment, a first domain contains the hard- 
ware and software components of the corporation's 
product development department, whereas a sec- 
ond domain contains the hardware and software 
components of the corporation's marketing depart- 
ment. A third domain contains the hardware and 
software components of the corporation's finance 
department, and a fourth domain contains the hard- 
ware and software components of the corporation's 
sales department. 

Each domain includes at least one domain 
controller 106. Multiple domain controllers 106 may 
be provided within each domain (see domain 108B, 
for example) so as to enhance availability and to 
provide load balancing of domain controller re- 
sources. Each domain controller is a distinguished 
machine. Figure 2 is a block diagram showing 
several major functional components of a domain 
controller 200. Each domain controller within the 
distributed system 100 includes the functional com- 
ponents shown in Figure 2 as well as additional 
components. The functional components within 
each domain controller 200 include directory ser- 
vice (DS) entries 202, which provide directory ser- 
vice information. Each domain controller also in- 
cludes a directory service (DS) server 204. The DS 
server 204 is responsible for mediating access to 
the DS entries 202. The DS entries 202 provide the 
naming service for the distributed file system and 
are described in more detail in copending applica- 



tion entitled "Unification of Directory Services With 
File System Services," which is assigned to a 
common assignee with the present application. 

A key distribution center (KDC) 206 is provided 

s in the domain controller 200 and plays a role in 
maintaining security within the domain. A distrib- 
uted file system (DFS) manager 208 is provided in 
the domain to manage knowledge about the distrib- 
uted file system and the volumes (described in 

w more detail below) contained within the domain. 
The distributed file system manager 208 also pro- 
vides functionality for facilitating distributed name 
resolution. Distributed name resolution involves re- 
solving a name in a distributed name space to a 

is physical address. The distributed file system man- 
ager 208 additionally provides management for a 
prefix table (described in more detail below) and 
management for knowledge about the file system. 
Before discussing the distributed file system in 

20 more detail, it is helpful to first introduce several 
concepts. An "object" is a logical structure that 
includes data structures for holding data and may 
include functions that operate on data held in the 
data structures. An object may hold just data with- 

25 out including any functions. In the distributed file 
system, both hardware components and software 
components may be modeled as objects. Modeling 
the data processing resources as objects insulates 
programs from needing to know the particulars of 

30 the resource. 

The objects provided within the distributed sys- 
tem 100 are stored in file system constructs known 
as "volumes". The volumes are organized hierar- 
chically (as will be described in more detail below). 

35 A volume is a unit of physical storage supporting a 
file system and a set of files and directories which 
comprise a persistent store of objects. Each do- 
main has its own volumes that hold objects for the 
domain and that define a name space that is local 

40 to the domain. 

Each volume has an associated volume object 
that holds information that allows distributed name 
resolution to be performed on the volume. Each 
volume object describes a single volume with a 

45 single entry path. The information includes an entry 
path to the volume and the identity of a file server 
for handling requests to access the volume. Vol- 
ume objects also store the entry paths for domains 
immediately superior to and immediately subordi- 

so nate to the domain containing the volume object. 
Entry paths for all volumes in the domain contain- 
ing the volume are also stored therein. 

The names of objects in the distributed system 
are organized into a distributed name space. Figure 

55 3 shows a simplified example of such a distributed 
name space 300 for a distributed system. The 
distributed file system makes the distributed name 
space visible. The distributed name space 300 is a 
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single logical tree structure that graphically repre- 
sents the named objects of the distributed system. 
The single tree structure provides a place for cen- 
tralizing knowledge about the system and facilitates 
access to the entire name space. The distributed 
file system hides junctions between machines and 
domain so that the distributed system appears 
seamless. Thus, the differences between file sys- 
tems present in the system and the differences 
between network operating systems present m the 
system are hidden in the distributed name space. 
Each name - in the distributed name space 300 
corresponds to an object within the distributed sys- 
tem. The domain folder objects each correspond 
with a domain controller. Each arc (see Figure 3) of 
the distributed name space 300 corresponds to a. ' 
portion of a path in the name space. The objects 
visible in the distributed name space need not all 
be file system objects; rather, non-file system ob- 
jects that are not available for file system oper- 
ations, such as a remote procedure call (RPC) 
server 358, may also be present in the distributed 

name space. 

The objects in the distributed name space may 
be divided by domain as shown in Figure 3 (note 
Domains W, X, Y and Z). It is worth noting that not 
all objects need be part of a security policy of a 
domain. Hence, there may be machines, collec- 
tions of objects or peripherals that lie outside trust 
policies of any domain. For instance, RPC server 
358 is not part of a domain. The objects in a 
domain form - a sub-tree of the distributed name 
space. Thus, domain X includes domain folder ob- 
ject 320, directory object 322, volume object 324 
and server object 326. Domain Y includes domain 
folder object 328, workstation object 330, directory 
object 332, document object 334 and volume ob- 
ject 336. Domain W includes domain folder object 
306, volume object 338, document object 340, di- 
rectory object 342 and document object 344. Do- 
main W also includes directory object 346. Direc- 
tory object 346 contains document objects 350 and 
352. Lastly, Domain Z includes domain folder ob- 
ject 308, workstation object 304, volume object 354 
and document object 356. 

The logical path name identifies an object, vol- 
ume or other component within the distributed 
name space 300. The distributed file system of the 
preferred embodiment of the present invention pro- 
vides a vehicle for resolving the logical path name 
to a physical address. 

The objects held for each domain may be 
divided into one or more volumes. For example, 
domain Y includes volume 310. Domain X includes 
volume 312; domain W includes volumes 314 and 
316; and domain Z includes volume 318. 

Two volumes are connected via logical con- 
structs known as "junction points." Junction points 



are composed of an "entry point" and an "exit 
point." An "entry point" is a logical path name 
which corresponds to the root of the name space 
for a volume or domain. For example, the logical 
5 path name "\b\c" corresponds to the root of vol- 
ume 310 which is logically contained within domain 
Y An "exit point" is a logical path name which 
corresponds to a point in the distributed name 
space at which another volume is attached. For 
10 example, the logical path name "\a" is an exit point 
from volume 312 of domain X into volume 314 of 
domain W. In the preferred embodiment, a given 
volume can have multiple exit points but can only 
have one entry point. "External junction points" join 
75 name spaces which are not available for file sys- 
tem operations with the distributed name space 
300. In Figure 3, an external junction point joins 
name space 319 with volume 312. It should be 
appreciated that external junction points permit glu- 
20 ing of external name spaces into the distributed file 

system. , 

"Logical roots" are programming invariants that 
refer to a point in the distributed name space 300. 
Logical roots are used to gain access to files and 
25 objects through the distributed name space 300. 
Logical roots are context-sensitive in that a, same 
logical root may resolve to different addresses on 
different machines. Logical roots typically identify 
the root of a domain, the root of a machine's name 
so space, or the root of all domains. Logical roots are 
shortcuts for directly accessing an object in the 
tree that forms the distributed name space 300 
without having to traverse the direct lineal ancestor 
objects. For example, Figure 3 illustrates that the 
35 logical path name "\b\c" is an entry point into 
domain Y. Such a logical path name may be asso- 
ciated with a logical drive letter such as "D:\," in 
order to create a logical root. In this way, logical 
path names, such as "\b\c\d", may be accessed 
40 using the path name "D:\d". Hence, the distributed 
name space 300 of Figure 3 may be traversed 
beginning at an object other than logical root node 
302. Logical roots are used to access objects 
throughout the distributed name space. 
45 As mentioned above, the preferred embodi- 

ment of the present invention uses these logical 
path names (which may include a logical root) to 
access objects in the distributed system 100 (Fig- 
ure 1). Figure 4 illustrates (from a high level per- 
50 spective) the steps performed to access an object 
when a request to access the object when a re- 
quest to access the object originates at a work- 
station. Copies of the access object routine are 
preferably stored on all workstations 101 of the 
55 distributed system 100 and on all domain control- 
lers 106 of the distributed system 100. Initially a 
request to access an object is received (step 402). 
For purposes of illustration, suppose that the re- 
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quest originates from workstation 500 shown in. 
Figure 5. The workstation 500 includes an in- 
put/output (I/O) unit 502, a central processing unit 
(CPU) 504, and a memory 506. In addition, the 
workstation 500 is connected to a keyboard 508 
and a mouse 510. The workstation memory 506 
holds a copy of a workstation operating system 
512, and at least one application program 514. The 
operating system 512 includes the access object 
routine 516; and a local file system driver 526 that 
is responsible for managing the local file system. 
The memory 500 also holds four other routines 
518, 522, 524 and 526 which will be described in 
more detail below. 

The request to access the object is forwarded 
to the CPU 504 of workstation 500. The CPU 504' 
executes the access object routine 516 and begins 
processing to fulfill the request. The request may 
originate from the application program 514 or from 
the operating system 512. For example, suppose 
that a query request is entered on keyboard 508 or 
on mouse 510. The query request to query an 
object is received by the input/output unit 302, 
which transfers the query request to the CPU 504. 
The CPU 504 extracts a logical path name of the 
object to be accessed (step 404). The logical path 
names, rather than the physical addresses, are 
provided by such requests. Accordingly, the logical 
path name must be converted into a physical ad- 
dress in the distributed system 100 that identifies 
where the object is stored (step 406). In other 
words, distributed name resolution must be per- 
formed. The operations entailed in this step will be 
discussed in more detail below. The object at the 
resulting physical address is then accessed (step 
408). It should be appreciated that the object may 
be located in the same domain as the workstation 
or may be located remotely at another domain or 
generally outside the domain. 

The distributed file system performs the dis- 
tributed name resolution required by step 406. Fig- 
ure 6 is a flow chart of a retrieve storage location 
routine 518 which performs the mapping of the 
logical path name of an object to a physical ad- 
dress for the object in the distributed system 100 
(i.e., step 406 of Figure 4). Copies of the retrieve 
storage location routine 518 are preferably stored 
in ail of the workstations 101 (Figure 1) and domain 
controllers 106 of the distributed system 100. 

Initially, the retrieve storage location routine 
518 receives the request to retrieve information 
from the distributed system 100 (step 602). For 
purposes of illustration, it is assumed that the re- 
trieve storage location routine 518 of the work- 
station 500 receives the request to retrieve the 
information from a local site in the distributed sys- 
tem 100. The logical path name for the object to be 
accessed is obtained from the request (step 604). 



A workstation prefix table 520 of the workstation 
500 is searched to determine if an entry for the 
logical path name obtained from the request is 
stored (step 606) in the prefix table. 

5 The workstation prefix table 520 is only one 

example of a prefix table data structure. Each do- 
main controller 106 includes a prefix table as well. 
Figure 8 shows the format of a prefix table 800 in 
more detail. The prefix table 800 acts as a cache 

10 for holding addresses for logical path names that 
have already been resolved. The prefix table 800 is 
used to map logical path names of objects into 
physical addresses in the distributed system. It 
should be appreciated that volumes have asso- 

75 ciated volume objects and hardware components 
typically have associated . objects that receive re- 
quests to access the volumes and components, 
respectively. A separate row or entry 802 is pro- 
vided for each logical path name held within the 

20 prefix table 800. Each row 802 includes a number 
of columns 804. Each column 804 holds a separate 
field. Column 806 holds the logical path name that 
uniquely identifies an object within the distributed 
name space. Column 808 holds a string associated 

25 with the logical path name of column 806 that is 
meaningful to an underlying network operating sys- 
tem (such as Microsoft LAN Manager, sold . by 
Microsoft Corporation of Redmond, Washington). 
The distributed file system of the preferred em- 

30 bodiment of the present invention is not a tradi- 
tional network operating system but rather is in- 
dependent of the network operating system and 
serves as a super-structure for tying together in- 
dividual network operating systems. 

35 Column 810 holds a local address that is 

meaningful to a local network operating system 
server or to a local file system. Column 812 holds 
a local volume flag. The local volume flag indicates 
whether the logical path name of . the row 802 

40 identifies a volume of the workstation that the user 
is logged onto. Column 814 holds a local exit point 
flag. The local exit point flag indicates whether the 
logical path name of the row 802 represents an exit 
point for a local volume. Column 816 holds a 

45 referral service flag that indicates whether the logi- 
cal path name of the row 802 represents a logical 
path name for a domain folder object. Lastly, col- 
umn 818 holds an inter-domain volume flag. The 
inter-domain volume flag is set whenever the vol- 

50 ume having the logical path name of the row 802 is 
stored in a domain outside of the domain contain- 
ing the prefix table. 

If all the logical path names of the distributed 
name space 300 for the distributed system 100 

55 were stored in the workstation prefix table 520, 
then the mapping of the logical path name for the 
object would only entail a simple lookup of the 
logical path name and a retrieval of the corre- 
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. . ^ 0 unwpver as the distributed sys- 

rr zz - 

1° en tens ot thousands of hardware and software 

comes Lpractica. due to the sheer size of such a 

^TnC' 606. the retrieve storage location rou- 
cno rib searches the workstation prefix table 520 
Tth U^sHogica. path name which is a prefix 
of the logical path name from the request. In other 
worts the workstation 500 first wants to d.scover 
Tether it already possesses the , regu, e now. 
edae to complete name resolut.on for the og.ca. 
name The notion of a prefix for a log.ca J path 
name' is perhaps best explained by example. For 
«i "ixb^Ms a prefix of logical path name 
^» TheL est matching prefix found in step 
606 -may be. equivalent to the entire logical path 
name o7 may match only a leading port,on of the 
Zeal pa* name. In step 608. the retneve storage 
ocSon routine 520 determines if there was a 

P 1' hedTleSmg portion of the logical name). If 
rnatched a leading P e(J wnetner the 

ra^heTentry^he workstation prefix table 520 
has its local volume flag set in column 812 (step 
6?0) I other words, it is determined whether ^ the 
obit having the logical path name is within a local 
vo ume for the workstation. If the local volume flag 
i S S the local address is retrieved from column 
810 of the prefix table and the logical path name 
from he request is translated by substituting the 
retrieved local address for the matched portion of 
^logical path name (step 612). Control , hen 
returned to the access object routine 516 (see 

^TinUp 610 it is determined that the matched 

t Z the object is then sent indijecjy ^ 
work server at the retrieved network address (step 
S£ The request is actually sent to a redactor 
^t tnenMnds the request to the network : «*r. 
The oerform server name resolution routine 522 is 
JTen catd "o perform name resolution at the serv- 

" ( TJI & 7 shows a flow chart of the steps per- 
formed by the perform server name resolution rou- 
^522 A ioglca. path name is obtained from the 



request to access the object that is sent to the 
/cton 702^ The network server 103 deter 

network server accesses the information held in the 
server s prefix table to perform name ^esolu^ 
tTpo: completion of £ £ 

5t8 » in step 706 it is determined that there was 
not a match between the logical path name and 
f5 X 3 of enSes in the server prefix table for a loca 
• volume, a distinguished error is retu ned to the 

S "e X inched within any .oca. volume 
the server (step 710). Upon completion of step 
20 "o* rowing control is returned to the retneve a 
storage location routine 518 at step 620. 

After the server name resolution routine 522 is 
JvZJi <s\eo 618). a determination is made 

a working prefix table entry (identifying the 
the JZ,^ <»»'• -«v «*« » » ^ 

rr:rors^rrr-rfi 

« ^udS an ent^ path ,or the vo.ume, a provrjr » 

45 Ten., in « pr.«* table 

'^rJtep^. if the working prefix table , e*ry 
indicates that referrals can be issued (i.e.. the 

55 ?3JS ;,T,r.a, ( £p W. ™s rootina 
l^Td^rXd m more detail helow. The wo* 
Itato then stores the information derived from the 
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referral in the prefix table 520 (step 630). 

If at step 608 it is determined that the prefix 
table does not contain a matching prefix for the 
logical path name contained within the request, the 
workstation 500 then looks for help from the do- 
main controller. Specifically, the working prefix ta- 
ble entry is set to refer to the prefix table of the 
domain controller of the domain containing the 
workstation from which the request originated (step 
632). The steps described above beginning at step 
624 are then repeated at the domain controller until 
the logical path name is resolved to an address. 

Figure 9 is a flowchart of the steps performed 
by the get referral routine 524. Initially, in step 902, 
the request for a referral is received at the domain 
controller associated with the working prefix table 
entry. The logical path name for the object to be 
accessed is extracted from the request (step 904). 
The prefix table at the domain controller that re- 
ceived the request is searched under the control of 
the DFS manager 208 for the longest logical path 
name which is a prefix of the logical path name 
from the referral request is searched (step 906). A 
determination is then made if there is a match 
between any of the prefixes in the table and the 
logical path name (step 908). If there is not a 
match, then in step 908, a referral is constructed 
by obtaining the network address (i.e., held in 
column 808 of the prefix table) for the domain 
controller of the immediately superior domain (step 
910). The referral is sent from the domain control- 
ler to the workstation that requested the referral 
(step 920). Control then returns to the retrieve a 
storage location routine 518. 

If in step 908 it is determined that there is a 
match, then it is determined whether the matched 
logical path name refers to a volume outside the 
domain of the domain controller, by checking 
whether the inter-domain volume flag is set as 
"False" (step 912). If the inter-domain volume flag 
is set as "False", a referral is constructed from the 
matched prefix table entry (step 913) and the refer- 
ral is forwarded to the workstation holding the de- 
sired volume (step 920). If the inter-domain volume 
flag is set to "True", then processing continues 
with step 914. 

In step 914, the referral service flag is checked. 
If the referral service flag is set to "False", the 
prefix table of the domain controller is searched for 
the longest logical path name which is a prefix of 
the logical path name in the currently matched 
prefix table entry (step 916). Processing continues 
by repeating step 914 (described above). 

If in step 914 it is determined that the referral 
service flag is set to "True", a referral is con- 
structed by obtaining the network address of the 
domain controller from the currently matched prefix 
table entry (step 918). Upon completion of step 



918, processing continues with step 920 wherein a 
referral is sent to the workstation which requested 
the referral. Control then returns to the retrieve a 
storage location routine 518. 

5 As mentioned above, prefix tables are stored in 

each workstation 101 and each domain controller 
106. Each variety of prefix table must be initialized. 
The prefix table of a domain controller is initialized 
with data retrieved from volume objects represent- 

10 ing volumes in the domain, which stores the cor- 
responding domain folder object. 

Figure 15 illustrates the steps performed by an 
initialize a domain controller prefix table routine 
1104, which initializes prefix tables in domain con- 

75 trollers using data stored in volume objects. Figure 
11 illustrates several components of a domain con- 
troller 1100 that are used in such initialization. In 
step 1502, the initialize domain's root volume local 
information routine 1106 is called. Figure 10 illus- 

20 trates the step performed by this routine 1106. In 
step 1001, the entry path of the domain's root 
volume is retrieved from the volume object of -the 
root volume for the domain containing the domain 
controller 109. An entry is created in the domain 

25 controller prefix table 1102 and the retrieved entry 
path is stored in the created entry (step 1003). The 
local address of* the root volume is retrieved from 
the volume object of the root volume and the local 
address is stored in the entry (step 1005). The 

30 local volume flag 812 in the entry is set (step 
1007). In step 1009, the network address of the 
domain's root volume is retrieved from the volume 
object of the root volume, and the network address 
is set (step 1007) in the entry of the domain 

35 controller prefix table 1102. In step 1011, the refer- 
ral service flag 816 in the entry of the domain 
controller prefix table 907 is set. The volume object 
is searched for the domain's root volume to deter- 
mine if unprocessed exit points for the domain's 

40 root volume still exist (step 1013). Exit points for 
the domain root volume are determined by simply 
examining the entries loaded into the prefix table of 
the domain controller for all domain volume ob- 
jects. If unprocessed exit points exist in the volume 

45 object, processing continues with steps 1015 
through 1021. 

In step 1015, the first unprocessed exit point is 
retrieved from the volume object for the domain's 
root volume. In step 1017, it is determined whether 

50 there is an entry in the domain controller prefix 
table 1102 for the exit path of the retrieved exit 
point. If there is not an entry in the domain control- 
ler prefix table 1 1 02 for the exit path, then an entry 
is created in the domain controller prefix table 1 102 

55 for the exit path of the retrieved exit point. Upon 
completion of step 1019, processing continues with 
step 1021. If in step 1017, an entry in the domain 
controller prefix table 907 for the exit path of the 
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S JoU^E- in step .0,5 * *»■ Upon com- 
pSTof aw 102., »"»" ueS "* 

^^"^^0*0 ,,08 ,e»«s » 

JL in the domain still exist (step 1202). it un 
^seTJ^ objects exist 
the non-root volume is retrieved (step 1203) and a 
^te minSion is made whether there is already an 
entrv in the domain controller prefix table 1102 for 
the entry path of the non-root volume associated 
with *e first unprocessed volume object ■ (step 
TJ 0 4) If there is not an entry in the domain corrtro - 
er ore fix table 1102 tor the entry path of the non- 

domain controller prefix table 1102 (step 1214). 
aomcun ^ processing contin- 

Upon ^^^Jilw. H is determined 
ZTeToVrcol^U, table 1204 con- 
Tans an entry for the entry path of the non-root 
*~ r,mrp<?sina 1102 continues with step 120b. 
: rio, address of the non-root 
r%L is retrieved from the volume object. The 
S eved n^ address is stored in the entry of 
rdomain controller prefix table 1102 ^ conta.n.ng 
the entry path for the non-root volume (step 1208). 
Upon completion of step 1208. process.ng confin- 

U6S S n sCl S 202 i determined that a„ volume 
obiects for non-root volumes have been processed, 
2n control returns to the initialize a doma.n con- 

110 2 has been initialized with the doma.n's root 



S) the n ti ale a domain controller prefix table 
Se 1104 invokes an initialize inter-domam .n- 

Z fo nS confer (stop If ""C^ d 

controller prenx WOM * . t such an 

zo entry, an entry m v retrieved entry 

^^rn^rrp^priss 

Upon ~Wl«on of J deMm lned 

table 1102 for the entry path o the root 
. votulTlovod fron, « ««- ^ ™ 

M 'if «i n.8,. Upon cojnpwon of step U.S. 
oJ^lTroot volumes of ImmodMsly supeno, 

controller prefix table routine 110*- the 

Upon return of process.ng control rom 
initialize inter-domain Z^^S 
45 initialize domain controller prefix J** •Jj 9 tnQ 

=:3:==K== 

C0P Trfrefix table in a workstation of the distributed 
on the workstation; the entry path of the dom 
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containing the workstation, along with the physical 
address of the domain controller of the domain; 
and the physical address of any storage device 
local to the workstation. 

Figure 14 illustrates the preferred steps of a 
routine to initialize a workstation prefix table. In 
step 1402, the routine to initialize a workstation 
prefix table determines if the workstation prefix 
table has been initialized with information about all 
local volumes on the workstation. If unprocessed 
local volumes still remain, the routine retrieves the 
entry path of the unprocessed local volume from 
persistent storage on the workstation. The retrieved 
entry path is stored in the workstation prefix table 
(step 1404). The local address of the unprocessed 
local volume is retrieved from persistent storage' 
and the local address is stored address in the 
prefix table (step 1406). The local volume flag is 
set in the workstation prefix table (step 1408). A 
determination is then made whether the workstation 
prefix table has been initialized with information 
about all exit points for this local volume on the 
workstation. If the workstation prefix table has not 
been initialized with information about all exit points 
for this local volume, information about the first 
unprocessed exit point is retrieved from permanent 
storage (step 1412). In step 1414 it is determined if 
there is an entry in the workstation prefix table for 
the exit path of the retrieved exit point. If there is 
not an entry in the workstation prefix table, an entry 
is then created in the workstation prefix table for 
the exit path of the retrieved exit point (step 1416). 
Upon completion of step 1416, processing contin- 
ues with step 1418. If in step 1414 it is determined 
that there is an entry in the workstation prefix table 
for the exit path of the retrieved exit point, process- 
ing continues with step 1418. 

In step 1418, the local exit point flag is set for 
the entry in the workstation prefix table that con- 
tains the exit path for the retrieved exit point. Upon 
completion of step 1418, processing continues with 
step 1410 again 

If in step 1410 it is determined that the work- 
station prefix table has been initialized with in- 
formation about all exit points for this local volume, 
then processing continues with step 1 402. 

If in step 1402 it is determined that the work- 
station prefix table has been initialized with in- 
formation about all local volumes on the work- 
station, then the entry path of the root volume for 
the domain containing the workstation is retrieved 
(step 1420). In step 1422, the network address of 
the domain controller for the root volume of the 
domain containing the workstation is retrieved. An 
entry is created in the workstation prefix table and 
the retrieved entry path is stored in the retrieved 
network address in the entry (step 1424). In step 
1 426, the referral service flag is set for the created 



entry in the workstation prefix table. 

Thus, it will be appreciated that, although a 
specific embodiment of the invention has been 
described herein for purposes of illustration, var- 
5 ious modifications may be made without departing 
from the spirit and scope of the invention. Accord- 
ingly, the invention is not limited except as by the 
appended claims. 

w Claims 

1. In a distributed system having a distributed 
name space of objects wherein each object 
has both a logical name uniquely identifying 

75 the object in the distributed name space and a 

corresponding address, the objects being 
grouped into logical domains which are or- 
ganized into a hierarchical structure wherein 
each domain may have one superior domain in 

20 the hierarchical structure and one or more sub- 

ordinate domains in the hierarchical structure, 
a computer implemented method for accessing 
an object comprising the steps of: 

providing a domain controller component 

25 for each domain, each domain controller com- 

ponent holding a prefix table which stores an 
entry for a logical name in the distributed 
name space of a domain controller component 
for any immediately superior domain land an 

30 entry for the logical name in the distributed 

name space for any domain controller compo- 
nent in any immediately subordinate domain, 
each said entry including an address of the 
domain controller component; 

35 providing a first computer component for 

processing requests for information from the 
distributed system, the first computer compo- 
nent including another prefix table which stores 
entries for prefixes of logical names in the 

40 distributed name space and each entry in- 

cludes an address of an object in the distrib- 
uted system that is named by the prefix; 

receiving a request to access the object at 
the first computer component, wherein the re- 

45 quest includes a logical name for the object to 

be accessed in the distributed system; 

determining if an entry for a prefix of the 
logical name from the request is stored in the 
prefix table of the first computer component; 

so in response to a determination that an en- 

try for a prefix of the logical name is not stored 
in the prefix table of the first computer compo- 
nent, 

retrieving from the prefix table of the first 
55 computer component the address of the do- 

main controller component for the domain con- 
taining the first computer component; 

sending the logical name from the request 
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domain containing the first comp 
Retrieving from the prefix table of the do- 

the request; and retrieved ad- 

the request. 

of claim 1 wherein the first com- 
2 . The method of claim ^ 

address for the portion of memory. 



70 



75 



* h nf rlaim 2 wherein the distributed 

S W me .« »^ 

an address at the network server. 

th „H nf claim 3, further comprising the 
4 - \ hem o fw2 e r he resolution of the logical 
step of where > in sefver 1S 

name to an addre ** * ™ ess t0 acC ess the 
successful, using the address w 

object. 

5 . The method of claim 4, further comprising the 

SteP where the resolution of the logical 

an Tddress at the network server is not sue 

cessful. 



orefiy table of the first 

t0 the domain controller < ^puter compo- 
domain containing the first compu 

nent '" ♦ • nn from the prefix table of the do- 

« request and ^ ^ 

the request. 
6 The method of claim 1 

* the domain ^ ^^oZ^ 

the physical address. 

.. j _ f ctaim 1 wherein the step of 
7. The method of claim i . mponen t in- 

a ,el» sup**; *^ /^"J. m** n»- 

troller component. 

35 8 The method of claim 1 wherein the logical 
name is a logical path name. 



9 . h.d^^J-J^S^ 

,ogically Pa rtitioned '"lain includes a do- 

nishes a distributed name space to 

the distributed system; workstat ion to 

^oSTTi ^tributed name 

aCC a c S e saw request identifying the object by 
space, saia requ e> 
its .ogical name -n he debute ^ 

providing a first cacno » the 
and associated resolved addresses 

55 workstation; workstation 

accessing the first cacne a 
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requested that has already been resolved to an 
address; 

where it is determined by accessing the 
first cache that a portion of the logical name 
has not already been resolved to an address, s 

forwarding the request to a domain con- 
troller for the domain that contains the work- 
station; 

providing a second cache at the domain 
controller of associated resolved addresses for 10 
logical names; 

accessing the second cache to determine 
if a portion of the logical name of the object to 
which access is requested has already been 
resolved to an address; rs 

where it is determined by accessing the 
second cache that a portion of the logical 
name of the object to which access is re- 
quested has been resolved to an address, 

forwarding the portion of the logical name 20 
and the address to the workstation; 

storing the portion of the logical name and 
the address in the first cache at the work- 
station; and 

repeating the above steps beginning with 25 
the accessing the first cache step. 

10. The method of claim 9, further comprising the 
steps of: 

where it is determined by accessing the 30 
first cache that a portion of the logical name of 
the object to which access is requested has 
already been resolved to an address, 

determining whether the address of the 
portion of the logical name refers to a storage 35 
location in the local storage of the workstation; 
and 

where the address portion of the portion of 
the logical name refers to a storage location in 
the local storage of the workstation, accessing 40 
the object using the address of the portion of 
the logical name. 

11. The method of claim 10 wherein the distrib- 
uted system further comprises a network serv- 45 
er and the method further comprises the steps 

of: 

where it is determined that the address of 
the portion of the logical name refers to a 
storage location outside local storage of the 50 
workstation, 

forwarding the logical name to the network 
server; and 

attempting name resolution of the logical 
name in an address at the network server. 55 

12. The method of claim 11, further comprising the 
steps of where the name resolution at the 
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network server is successful in resolving the 
logical name to an address, using the address 
to access the object. 

13. The method of claim 11, further comprising the 
steps of: 

where the name resolution at the network 
server is not successful in resolving the logical 
name to an address, 

forwarding the logical name to a second 
domain controller for a domain which includes 
the portion of the distributed name space iden- 
tified by the portion of the logical name that 
was determined to be resolved by examining 
the first cache at the workstation; 

providing another cache of logical names 
and associated resolved addresses at the sec- 
ond domain controller; 

accessing the cache at the second domain 
controller to find an address for a portion of the 
logical name that has already been resolved; 

forwarding the found address to the work- 
station; and 

storing the found address and associated 
portion of the logical name in the first cache at 
the workstation. 

14. In a distributed system having a first storage 
media partition and a second storage' media 
partition, a method comprising the steps of: 

running a first file system on the first stor- 
age media partition of the distributed system 
for storing and managing files; 

running a second file system on the sec- 
ond storage media partition for storing and 
managing files, wherein the second file system 
differs from the first file system; and 

providing a distributed file system that fur- 
nishes a single distributed name space with 
files in the first storage media partition and 
files in the second storage media partition and 
that furnishes name resolution services to the 
first file system and the second file system for 
the distributed name space, wherein the dis- 
tributed file system is transparent to the first 
file system and the second file system. 

15. A distributed system comprising at least one 
storage media comprising: 

a first storage media partition running a 
first file system for storing and managing files; 

a second storage media partition running a 
second file system for storing and managing 
files, said second file system differing from the 
first file system; and 

a distributed file system for supplying file 
name resolution services for the file systems 
and for furnishing a single distributed name 
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space that includes files from the first storage 

and the second file system. 

<* m a distributed system having computer sys- 
16 ' Tems^h files stored therein, a method com- 

tem onTne of the computer systems wherein 
t h T network operating system differs from the 
first network operating system; and 

Dividing a distributed file system over the 
network ope^ting systems that furnishes name 

unified distributed 
system * distributed system. 

on the computer system running the first net 

opera^g system and the second network op- 
erating system. 

tnereTat least one of said computer systems 
unnTng a first network operating system and at 
ZZ ! one of said computer systems runn.ng a 
l^cond netork opening system that differs 
? r0 m the first network operating system; and 

a distributed file system layered over the 
neJorkterating ?™££!S?£Z 

9 . a L for oroviding a distributed name 
See of f e wherein laid distributed name 
soace includes files stored on the computer 
P y Sm running the ^network operating , sys- 
tem and files stored on the computer system 
unning the second network operating system 
and wherein the distributed file system s 
transparent to the first network operating sys- 
E^STthe second network operating system. 



providing a distributed file system for fur- 

*™ rr"— operating 
running a netwQrk operat . 

and i mP .ementing a second secunty po^on 
♦ ho r.r^t domain that differs from the first secu 

- cond po,i t c i be,n9 

dependent of the distributed file system. 
19 . ,n a distributed system, a method comprising- 
^pSng a distributed file system that pro- 
„\r\^ a distributed name space, 
15 ^"prov^ng at least one under.ying We sys- 

tem for performing filing system operations 

making objects upon which file system op- 
erations may be performed visible in the d.s- 

20 ^trgTSrorobiect which ,e sys- 

tem operations may not be performed visible 
in the distributed name space. 



18 . ,n a distributed system having multiple compo 
nents. a method comprising the steps of. 

loaically partitioning the components of the 
nist Xed system into domains, including a 
llin each domain being self-contained 
Sch that tt may operate independently of oth- 
er domains; 



an address for a corresponding prefix 

in the domain controller of the secon 
that refers to the domain controller in tne 

domain; . the domain 

Tl; 9 thnecond X the 
45 S^tSrSs to the domain controller 

table in the domain controller in the first do 

""fusing the first referral to access the prefix 
table in the domain controller in the first do- 
main to obtain the second referrahand 
using the second referral to access 
ss object. 
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second referral refers to a logical name in the 
third domain. 

22. The method of claim 21 wherein the distrib- 
uted system includes a network server in the 5 
first domain wherein the second referral refers 
to the network server in the first domain and 
wherein the step of using the second referral 
to access the object comprises the step of 
using the second referral to access the net- 10 
work server in the first domain and accessing 
the object via the network server. 
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